Now that we have defined the format of the protocol messages, we can begin to discuss how the server and client should handle and respond to particular messages. Each message sent, either by the client or server, must receive a response with a matching keyword and transaction ID. The response that is sent depends on the type of message. Requiring each message to be met with a response ensures that the sender knows that the receiver has actually received and processed that particular message. 

Messages are separated into two distinct types, which are the following:

\begin{itemize}
\item \textbf{Action Messages} These types of messages are single actions such as logging in, sending a message or updating a password, or any kind of action that expects only a ``success'' or ``failure'' response. Upon receiving an action message, the receiver should process it and respond with same keyword, same transaction ID and a single argument containing either “TRUE” or “FALSE” to indicate if the action completed successfully. Client action messages have keywords prefixed with ``CA\_'' and server action messages have keywords prefixed with ``SA\_''.

\item \textbf{Request Messages} These are messages which expect some sort of data response such as a list of users currently in a channel, getting the current status of a user or a list of users in your contact list. As before, the receiver should respond to this type of message with the same keyword and transaction ID, however after which any arguments depend on the particular message that is sent. It is intended that only the client shall make request messages however there is no particular restriction against the server making request messages in the protocol. Client request messages have keywords prefixed with ``CR\_''.
\end{itemize}

Messages are split into these two types for the sake of logical categorisation -- action messages being messages that ask the receiver to perform some sort of specific action, and request messages being messages that perform some sort of query on the receiver, expecting a data response. This helped when defining the protocol specification, as we could think more clearly about the types of responses that should be returned along with what the ordering of that response should be. It also helped to simplify the network architecture as explained later on in this report.

A full protocol specification is given in appendix A.